Prior to manufacture of an integrated circuit, designers verify the functionality of their designs (referred to herein as the “design under verification”, or “DUV”). The DUV is usually provided in the form of a netlist description of the design. The netlist may have been derived from many sources, including from a hardware description language. A netlist description (or “netlist”, as it is referred to by those of ordinary skill in the art) is a description of the circuit's components and electrical interconnections between the components. The components include all those circuit elements necessary for implementing a logic circuit, such as combinational logic (e.g., gates) and sequential logic (e.g., flip-flops and latches).
Design verification is performed because fabricating an integrated circuit is expensive and takes time. If the circuit design contains functional errors, the design will have to be corrected and then re-fabricated. Thus, many different platforms for functional verification of integrated circuits have been developed. Hardware-based design verification systems such as logic emulation systems are known devices that implement a user's design in a plurality of programmable integrated circuits. Such logic emulation systems are available from various vendors, including Cadence Design Systems, Inc., San Jose, Calif., United States of America, and others. Typical emulation systems utilize either programmable logic chips or processor chips that are programmably interconnected. In processor-based emulation systems, the DUV is processed so that its functionality appears to be created in the processors by calculating the outputs of the design. The logic itself is not implemented in a processor-based emulation system. Examples of hardware logic emulation systems using processor chips can be seen in, e.g., U.S. Pat. Nos. 5,551,013, 6,035,117 and 6,051,030. U.S. Pat. Nos. 5,551,013, 6,035,117 and 6,051,030 are incorporated herein by reference.
Another type of design verification system is known as a software simulator. Software simulators differ from hardware verification solutions in that the simulation software is executed in general-purpose computers rather than in specialized hardware like an emulation system. Simulation is a software-based approach, in which the DUV (or a portion thereof) and testbench are compiled into machine executable model and executed in workstation or PC. A testbench is a series of test vectors (i.e., stimulus) that are used to stimulate a design and may include modules that receive the outputs from the DUV after the vectors are run in the DUV. Since most electronic designs are presently designed using hardware description languages (“HDL”) such as Verilog, a testbench is typically comprised of some HDL code.
Hardware-based verification systems and software-based verification systems each have benefits that the other lack. For example, software-based verification systems allow for very accurate verification using the exact timing (i.e., clocking) that the actual DUV will encounter when installed in a real electronic system. Software simulators allow a user to see the result of every logic operation and can graphically represent the signal transitions from high to low or from low to high on a computer monitor. While hardware-based verifications systems do not normally have this ability, hardware-based systems are orders of magnitude faster than software-based systems and therefore provide very fast verification.
In order to debug a DUV, the designer needs to look into activities of design signals over time. The reason for this is that digital circuits are driven by one or more clocks, and errors can occur at various transitions of the clocks driving the DUV. The designer faces at least two issues when evaluating design signals over time. One issue is which signal to observe (i.e., which node in the DUV to observe). A second issue is when to observe the signals (i.e., at what clock transition and/or which confluence of events—sometimes referred to as a trigger). These two issues impose serious challenges to simulation and emulation tools. First, circuit designs are typically very large (e.g., in the order of million gates). Second, the number of signals the designer would like to observe is proportionally large. Third, since the time window in which design signals need to be observed (referred to herein as the “trace window”) is hard to predict prior to simulation or emulation, the designer who is debugging a design would prefer the trace window to be as large as possible.
In order to handle these issues, circuit designers have used various approaches. One such approach is to run the DUV lockstep in a simulator. With this approach, progress of simulation is controlled by the designer in interactive operation. Designers can run simulation, stop and observe signals, continue, and repeat the process. When simulation stops, designers can check the state of any signal in the design. A second approach is to perform free running simulation with signal dump. With the “free running” approach, simulation is executed freely without user intervention, and signals to be observed during simulation are dumped out during simulation. It is important to note that the signals to be dumped out must be specified before the simulation starts. These simulation approaches, while effective, are very slow. A third approach is to emulate the DUV using an emulator that allows full visibility for a fixed size of trace window. In this approach, the emulator is running freely, and signals generated by the DUV in the emulator that allow for full vision are saved for a certain period of time. A final approach is to emulate the DUV with an emulator that provides for limited visibility and replay. With this approach, limited information is saved during emulation. Designers might need to run emulation a few times in order to get sufficient information for analysis.
As discussed, one way of using a hardware-based verification system is in conjunction with a software simulator. This is sometimes referred to as simulation acceleration. Because emulators operate at speeds that can be orders of magnitude faster than simulators, emulation systems, and in particular, processor-based emulation systems, contain vast amounts of information about the state and activity in the emulated circuit. The reason for this is as follows. Simulators allow designers to view the state of a signal as it exists at a specific node in the DUV at a specific time (i.e., clock cycle) immediately after a single cycle of a simulation. A simulation cycle is the amount of time (and thus the state changes that take place) during one step of the fastest clock driving the DUV. In other words, a simulation cycle is the time of interest during a verification operation because any signal transitions that take place during simulation cycle are typically not relevant. The only signal transitions that generally are important in a DUV are the signal transitions that exist at the end of one simulation cycle.
In simulation environments, the stimuli that drive the DUV during a simulation cycle are modeled on the workstation. In contrast, in simulation acceleration environments, the stimuli driving the DUV are sent to the emulator that is emulating the DUV, and the response is then sent back to the simulator. Because emulators run the DUVs at clock speeds that are dramatically faster than simulators, simulation acceleration can dramatically decrease the amount of time it takes to verify a DUV.
User interfaces and software simulators need constant access to this state information in order to make simulation acceleration worthwhile. Simulation engines also need immediate responses to state changes in the emulated circuit to continue simulation, which requires low latency (i.e. the simulator and the emulator generally need to run in lockstep mode). In addition, the sheer volume of data required and made available in a large emulation requires a high bandwidth connection.
The cycle time for simulation acceleration is generally defined as the amount of time it takes to send signals from the simulator to the emulator, the time the emulator takes to calculate what changes occurred in the signals running through the DUV, and the time required to send those changes back to the simulator running in the workstation. Latency, which is a key issue in simulation acceleration, is the amount of time it takes to get a response from the emulator. For simulation acceleration to be a useful verification method, latency must be reduced as much as possible.
At least one prior solution exists that attempts to provide low latency and high bandwidth between the hardware-based verification system (e.g., the emulator) and the software-based verification system (e.g., the simulator). In one prior solution, the software simulator accesses the states of the emulator by querying the emulator through a high latency Ethernet path to a local processor in the emulator and then across an address/data handshake path to access individual components in the emulation system. In a second prior solution, the Direct Attach Stimulus (“DAS”) interface connects to a series of register circuits programmed into the emulated logic of the DUT. Software simulation accesses are grouped into a burst of data into and/or out of these registers. This burst of data is transferred across a 31 bit data path between the emulated registers and a memory buffer on the PCI card in the workstation. The simulator hands the data to a “DAS driver”, which formats it and transfers it to the PCI memory buffer and initiates the transfer. Once complete, the driver transfers the return data back to the simulator's buffer. The DAS card is a product available from Cadence Design Systems, Inc., San Jose, Calif., that provides for communication between a simulator running in a workstation or personal computer and an emulator.
A problem with the first prior approach is that the network path to the embedded processor in the emulation system has very high latency due to the reaction time of the local processor that receives the request, accesses the appropriate element(s) in the emulation engine, then formulates a response, and sends it across the network to the workstation application.
In the prior art DAS architecture mentioned above, as in many workstation interfaces, latency and bandwidth are dependent upon the input/output (“I/O”) subsystem of the workstation, the PCI bus, local hard disk accesses, and access to I/O resources such as DMA engines. This is true for the setup of the transfer as well as the transfer itself. In addition, in the previous DAS architecture, only 31 bits of each 32 bits within workstation memory could be used as emulation data due to hardware limitations. This results in an undesirable situation where long vectors of bits in the simulator could not be mapped directly to contiguous bits in the DAS packet buffer, requiring software to pack the bits in such a way as to avoid the gaps.
Because simulation acceleration is becoming more popular while the number of signals generated by the DUV being executed in the emulation system is increasing, there is a need for an improved means of transferring signals and instructions between simulators running in a workstation and emulators that are communicating with those simulators.